The National Institute of Standards and Technology (“NIST”) in 2002 released a report stating that software errors cost the U.S. economy $59.5 billion per year. As Web Services i.e. software receiving XML messages, processing them and returning XML messages, and can be also called (activity services, entity services, process services, business services, etc.) are quickly becoming the de facto standard software component model and will be created by the thousands, a skyrocketing portion of this cost will be related to Web Services and XML processing software. This NIST study found more than a third of that expense could be eliminated by improved testing that enables earlier and more effective identification and removal of defects. However, being able to do so, requires a completely new approach, the use of different programming technologies and languages, The scalable deployment of Web services mandates a technology that ensures the correctness of Web services at the development time and enables the automated change management of those services.
Today, the development paradigm for application development is object-oriented and is not adapted to the creation of this myriad of mini-applications called Web Services that are structurally defined as XML entities. The industry is currently applying its object oriented languages to Web Services. This is a mismatch.
Languages such as Java or NET C# are object-oriented. Objects contain data and methods. The behavior of the object is encoded inside the object as methods. The level of constraints expressed in an object is simple in terms of the data but can be extremely complex in terms of methods. To some extent this is because Java and NET C# are general languages for general needs, but not for all needs.
MS VS [Microsoft Visual Studio] and Eclipse both provide an “Intellisense” or “Intellisense-like” feature to help developers working in objected oriented languages. If, for instance, a developer types “custInfo.” and if custInfo is an object of type Customer info, then both environments displays a popup-menu listing the fields and methods of the Customer info class. This type-looking is based on static typing and is eventually nothing more than a dictionary lookup algorithm.
MS VS and Eclipse (using an underlying compiler, e.g. Javac) also provide the minimal checking (parsing errors, warning, . . . ) that developers expect from such studios. This checking can be performed at compilation time or in background depending on the product and speed of the machine one uses.
However, MS VS and Eclipse are incapable of certifying that a program is logically valid, that it follows constraints and that it will not have run time errors. As a result, the quality of a program entirely depends on human factors, which means that a program is largely unreliable. For example, the developer has to check for null references, unutilized variables, correctness of the input parameters and other fatal errors. For all these aspects and multiple others, the quality of the program relies on the quality and experience of the developers and oversights are extremely frequent.
In other words, with general object-based languages, there is no way to know, at design time that a program will not generate an unmanaged exception and/or crash with a run time error.
Hence the necessity, with object oriented languages, to address the following issues:
                Write test code while writing the code (extreme programming).        Follow good QA process to test the program.        Effectively use debugger Tools.        Employ good Technical and Customers services for addressing issues not detected during the QA phase.        
As an illustrative example, consider the development of a Web Service that processes an Account Balance Inquiry request that complies with the IFX 1.4.0 specification (BalInqRq message), and returns an Account Balance Inquiry Response (BalInqRs). The BalInqRq and BalInqRs are XML-based messages and are formally defined in the IFX 1.4.0 XML Schema. A fragment of this schema is as follows:
<xsd:element name=“BalInqRq” type=“BalInqRq_Type”></xsd:element><xsd:complexType name=“BalInqRq_Type”><xsd:sequence><xsd:element ref=“RqUID”/><xsd:element ref=“MsgRqHdr” minOccurs=“0”/><xsd:element ref=“AsyncRqUID” minOccurs=“0”/><xsd:element ref=“CustId” minOccurs=“0”/><xsd:choice><xsd:element ref=“DepAcctId”/><xsd:element ref=“CardAcctId”/><xsd:element ref=“LoanAcctId”/></xsd:choice><xsd:element ref=“IncExtBal” minOccurs=“0”/><xsd:element ref=“DeliveryMethod” minOccurs=“0”/></xsd:sequence></xsd:complexType>
What this means is that any BalInqRq message will start with a BalInqRq tag, which will contain:                a mandatory RqUID element,        an optional MsgRqHdr element (2 possible cases),        an optional AsyncRqUID element (2 possible cases),        an optional CustId element (2 possible cases),        then either a DepAcctId element or a CardAcctId element or LoanAcctId, but        not any 2 at the same time (3 possible cases),        and then an optional IncExtBal element (2 possible cases),        and finally an optional DeliveryMethod element (2 possible cases).        
Given this interface definition, and without even dealing with particular values when elements are present or showing the definitions of elements like CardAcctId, which may itself contain optional elements, choices, etc., we would in theory already require 2×2×2×3×2×2=96 test cases to cover the different possibilities.
This is an example of a valid BalInqRq:
<BalInqRq><RqUID>f81d4fae-7dec-11d0-a765-00a0c91e6bfb</RqUID><MsgRqHdr><NetworkTrnInfo><NetworkOwner>ATM</NetworkOwner><TerminalId>22222</TerminalId><BankId>10255000017</BankId><PostAddr><Addr1>93 Dalma Drive</Addr1><City>Mountain View</City><StateProv>CA</StateProv><PostalCode>94041</PostalCode><Country>US</Country></PostAddr></NetworkTrnInfo><MsgAuthCode><MacValue>1234</MacValue></MsgAuthCode></MsgRqHdr><CardAcctId><CardMagData><MagDat2>;123456102132547692=0212</MagDat2></CardMagData><AcctType>DDA</AcctType></CardAcctId></BalInqRq>
With this one example, the case is tested where there is a MsgRqHdr, a CardAcctId, but no AsyncRqUID, CustId, IncExtBal or DeliveryMethod. In theory, a developer would need ninety five more test cases.
Furthermore, because a Web Service is defined not just by input XML Schema fragment(s), but also by output XML Schema fragment(s), any XML output resulting from testing must also be tested for compliance with the output XML Schema fragment(s).
When a test case either produces a runtime error or an XML output that does not comply with the XML Schema, the program must be modified. Any such modification may create new problems.
The main reason for this time consuming approach stems from the inability of languages like Java, C or C# to perform static type checking at compile time based on a type system that conforms to the XML Schema specification. For instance, in a Java program that manipulates XML instances of the previous XML Schema example, even though CardAcctId and LoanAcctId are mutually exclusive tags, there is nothing that will technically prevent the developer from making a mistake such as trying in to copy the content of CardAcctId while having already positively tested that the LoanAcctId exists.
Therefore, there exists a need for a system and methods that serve to prevent a developer from making such mistakes, detecting errors resulting from changes in the program, and ensuring overall program validity, without relying on extensive case-based testing. As will be seen, the invention enables such a system and method in an elegant manner.